home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 4156 < prev    next >
Encoding:
Text File  |  1996-08-06  |  6.0 KB  |  144 lines
  1. Newsgroups: comp.lang.java,comp.lang.eiffel,comp.lang.misc,comp.lang.c++
  2. Path: munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
  4. Subject: Re: Constness in languages (Re: java weaknesses and peculiararities)
  5. Message-ID: <9602901.11916@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU (CS-Usenet)
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <30FBED5F.28B8@achilles.net> <4dj4t4$a4@kai.com> <4e6dtm$si5@gaia.ns.utk.edu>
  9. Date: Sun, 28 Jan 1996 14:43:42 GMT
  10.  
  11. mbk@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Matthew B. Kennel) writes:
  12.  
  13. >Arch Robison (robison@kai.com) wrote:
  14. >
  15. >: The keyword 'const' looks innocent at first, but introduces many
  16. >: subtle complexities.  
  17. [...]
  18. >I think the problem with "const" as commonly known in C and C++ is
  19. >that their model has a subtle, but fundamental intellectual error. 
  20.  
  21. I disagree.  If you don't like `const' in C/C++, blame the subtle
  22. complexities, blame the old code you have to interface with, blame the
  23. language for not including `template on const', or blame the problems
  24. on `const' not being the default.  But don't put it down to
  25. intellectual error, because the C/C++ model of `const' is perfectly
  26. consistent.  It may not be the only model around, and it may
  27. conceivably not even be the best one, but I wouldn't call it erroneous.
  28.  
  29. Personally I find `const' an extremely useful feature in both C and C++
  30. and I am glad that they have it.  I think that if I used Java or
  31. Eiffel, I would miss it.
  32.  
  33. >Using Eiffelish terminology, "const" as typically done now is like
  34. >a *precondition*, but the actual idea that it is supposed to uphold
  35. >is really a *postcondition*.
  36.  
  37. No, the idea that "const" in C/C++ is supposed to uphold is a type constraint.
  38. A type consists of a set of values, and a set of operations on those
  39. values (e.g. initialize, inspect, modify, ...).  A const type has the
  40. same set of values, but a subset of the operations - only the ones that
  41. don't modify the object (e.g.  initialize, inspect, ...).
  42.  
  43. >The notion that there are "types" which can be "const"ed means that this
  44. >ends up---in some rough approximation---being a precondition to some
  45. >routines:  a restriction on what sorts of things can be passed to the
  46. >routine.
  47. >
  48. >However, that isn't really what we really want to express.  What you
  49. >really want to do is restrict the operation of the ROUTINE! 
  50. >
  51. >The idea is that the ROUTINE which is called must guarantee that the
  52. >reference which is passed "const" will not have modified data accessable via
  53. >that pointer. 
  54.  
  55. Types allow you to do that.  Given an ADT, a routine can only apply
  56. the operations specified by that ADT.
  57.  
  58. But types also allow you to do more.  Using postconditions only allows
  59. you to ensure the constness of references passed to a routine.  Using
  60. types also allows you to ensure the constness of references returned
  61. from a routine.
  62.  
  63. >The fundamental difference between pre- and post-conditions is that
  64. >preconditions put restrictions the caller, whereas postconditions
  65. >put restrictions on the callee.
  66.  
  67. Right.  And types can put restrictions on both.  Which is exactly what
  68. you want.
  69.  
  70. Anyway, postconditions aren't sufficient, because if you want to pass a
  71. reference to an object which is shared with another thread or which is
  72. stored in ROM) you also need to be able to prevent intermediate
  73. modifications.  Types will allow you to do that; postconditions won't.
  74.  
  75. >IMHO what you want for "constness" is a *post*condition which verifies:
  76. >
  77. >    "is_provably_const(argument)" for all arguments which should
  78. >    be 'const'. 
  79. >
  80. >{of course you should also permit is_provably_const(self)
  81. > is_provably_const(this) is_provably_const(Current) for distinguished
  82. > dispatch OO languages like ST, Eiffel, Sather, Java and C++}
  83. >
  84. >Then, the compiler would statically verify that "argument" was not changed,
  85. >and fields accessible through "argument" or any variable aliased to the same
  86. >object as that of "argument" were not changed, *and* that "argument"
  87. >was only passed to other subroutines in positions which ALSO asserted
  88. >"is_provably_const()" for the reference.  
  89. >
  90. >If the compiler is not able to do so, you will get a precise 
  91. >compile-time error.
  92.  
  93. How is the compiler going to know which variables are aliased to which
  94. other ones?
  95.  
  96. Are you supposing that the compiler should be required to do global
  97. aliasing analysis?  If so, what level of precision of analysis would
  98. you require?
  99.  
  100. That seems to me to be a very big problem for your approach.
  101. You are presuming that the compiler has perfect aliasing information
  102. at compile time.  But this is not the case in any of the languages
  103. under discussion.
  104.  
  105. >Think about this model.  Now, if you "constify" one routine, you
  106. >do NOT have this enormous chain of "reconsting" propagating throughout
  107. >the program as you do in C++.  
  108. >
  109. >Instead, only the further routines which are *called* by the modified
  110. >routines will have to be checked.  This is of course unavoidable as you must
  111. >in fact guarantee that constant things are really constant.   
  112.  
  113. I don't understand.  In C++, "constifying" one routine will not require
  114. any changes to its callers either, will it?
  115.  
  116. >Why has "const" been typically thought of as an implicit precondition?
  117.  
  118. "const" has *not* typically been thought of as a precondition.  It has
  119. been thought of as a type constraint, which is a somewhat different
  120. thing.  A type constraint on inputs is a precondition.  But a type
  121. constraint on values returned from a routine is a postcondition.
  122.  
  123. >SUMMARY:
  124. >
  125. >    Yes, the notion of "is not changed" a.k.a. "constancy" is
  126. >    a good one, but do NOT implement it as in C++ 'const'.
  127. >
  128. >    "constancy" is a *postcondition* on a routine, not a precondition.
  129. >
  130. >    Do not naively stuff it into types or argument signatures, which are 
  131. >    preconditions.
  132. >
  133. >    Implement it as statically checkable postconditions instead.
  134.  
  135. If these postconditions are statically checkable, then how do they
  136. differ from type constraints?
  137.  
  138. How is treating constancy as a postcondition any different to treating
  139. it as a type constraint?  What problem does it solve?
  140.  
  141. --
  142. Fergus Henderson                 WWW: http://www.cs.mu.oz.au/~fjh
  143. fjh@cs.mu.oz.au                  PGP: finger fjh@128.250.37.3
  144.